Communication control method and apparatus, and communication system

ABSTRACT

A printer has a queue for queuing a queued execution command, an immediate execution agent for executing a write command, and a queued execution agent for executing a read command. The immediate execution agent immediately executes the received write command, and writes data in a host. The queued execution agent picks up a read command from the queue, and reads out data from the host. The host appends a data transfer request from the printer to a queue, issues a write command to the printer on the basis of that data transfer request, and issues a read command to the printer on the basis of a print data transmission request or the like from an application. Independent full-duplex channels can be provided in two directions. Also, a write command can be immediately processed.

BACKGROUND OF THE INVENTION

The present invention relates to a communication control method andapparatus for connecting apparatuses such as a host computer andprinter.

In recent years, an IEEE1394 interface is used for connecting a computerand peripheral apparatus, or connecting peripheral apparatuses. TheIEEE1394 interface allows higher-speed, two-way communications ascompared to a hand-shake scheme such as a Centronics interface. Also,the IEEE1394 interface is a memory bus model interface, and equipmentsconnected via the IEEE1394 interface can read data from the designatedaddress of a connected equipment and can write data at the designatedaddress.

IEEE1394 defines the protocol of the physical and link layers utilizedin many applications, but does not define detailed protocols in units ofequipments. For this reason, the protocol of the transport layer such asSBP (Serial Bus Protocol)-2 that uses IEEE1394 as the physical and linklayers has been proposed. The transport layer provides a data transferfunction to an application, and applications which use this layer canexchange data with each other.

The protocol SBP-2 utilizes the features of the memory bus model ofIEEE1394, and with this protocol, the data receiving side can receivedata as its resources become available.

In SBP-2, when data is to be transferred, the transmitting side performsoperation called a login to establish a channel with a communicationpartner. In this case, the logged-in side is called an initiator, andthe partner is called a target. Data transfer is done in such a mannerthat the target reads/write data from/to the initiator in accordancewith an instruction from the initiator. In this scheme, the initiatorgenerates an ORB (Operation Request Block) that contains the storageaddress, size, and the like of data to be transmitted after the login,and informs the target of the address of that ORB. The target reads outdata from the initiator on the basis of the address and size written inthe ORB and processes the readout data, or writes data as its resourcesbecome available. After such processing, the target generates a statusblock to inform the initiator of the processing state.

When a communication is made using SBP-2 built based on IEEE1394,especially when SBP-2 is applied to data transfer from a data sourcesuch as a host computer or the like, which serves as an initiator, to aperipheral apparatus such as a printer apparatus, which serves as atarget, the following two problems are posed.

(1) The procedure is complex due to full-duplex communications.

In SBP-2, data transfer is basically managed by the initiator, and thetarget cannot asynchronously transfer data to the initiator. In SBP-2,when the target wants to transfer data to the initiator, it sends a dataread request using unsolicited status to the initiator. The initiatorgenerates an ORB in response to the request, and adds the generated ORBto the end of a list of pending ORBs (including a data transfer requestfrom the initiator to the target, and the like). These ORBs areprocessed in turn from the oldest one. For this reason, only-when theORB processing of the initiator side has progressed, and the initiatorprocesses the ORB generated in response to the data read request fromthe target, the target can transfer data to the initiator. That is, thedata transfer timing from the target to the initiator is not theissuance timing of the read request from the target to the initiator butis delayed from that timing by the time required for processing thepending ORBs. As a result, two-way, asynchronous data transfer cannot bedone. When data to be transferred from the target to the initiator isgenerated asynchronously, for example, when the target is a printer andan error occurs in that printer, the data to be immediately transmittedto the initiator cannot be transferred in real time.

For this reason, in order to transfer data asynchronously generated by aprinter to a host in real time, the printer must undertake a loginprocedure as an initiator, and must perform data transfer to the hostcomputer as a target.

In this way, when the host computer and printer log in each other, andthey both serve as an initiator and target, they must both own processesas an initiator and target. The printer must also perform a login.

A peripheral apparatus such as a printer which processes an imageconsumes large volumes of memory and processor resources for imageprocessing. For this reason, in order to reduce the cost by simplifyingthe apparatus arrangement and to attain quick processing, resources usedfor purposes other than image processing must be reduced as much aspossible. However, when the printer must run many processes, asdescribed above, many resources are consumed accordingly, thusdisturbing a cost reduction and efficient processing.

On the other hand, data that flow between the host computer and printerare related to each other like print data and its processing status. Ifchannels are set in two ways by independent login processes, their dataand responses must be related to each other, and a new processingprotocol therefor must be added.

In this way, it is inappropriate to directly apply IEEE1394 and SBP-2 tocommunications between the host computer and printer, and it is hard toreduce required resources in the respective apparatuses and to improveefficiency.

(2) Multi-channels cannot be realized.

Recently, a multi-functional machine that combines various functions ispopularly used as a peripheral apparatus. For example, a digitalmulti-functional machine which allows a host computer to use it as ascanner, printer, and facsimile is known. When such apparatus is used, aplurality of functions can be simultaneously used if communications aremade via a plurality of independent channels in units of functions.

However, since SBP-2 cannot provide multi-channels, it is difficult touse such unit functions simultaneously.

Some protocols other than SBP-2 can transfer asynchronously generateddata and can realize multi-channels. However, such protocols cannotutilize the features of IEEE1394 as the memory bus model. That is, whensuch protocols are applied to communications between the host andprinter, the printer cannot perform data transfer at its convenience,and the host must perform data transfer while monitoring the printerstate.

SUMMARY OF THE INVENTION

The present invention has been made in consideration of theaforementioned prior art, and has as its object to provide acommunication control method and apparatus, which can make full-duplexcommunications (asynchronous two-way communications) by a single loginprocess, and can efficiently utilize resources such as processes,memories, and the like required for data exchange, and a printerapparatus using the method.

It is another object of the present invention to provide a communicationcontrol method and apparatus, which allows a target to read out dataprepared by an initiator as soon as its resources become available, andcan prevent the initiator from being occupied by data transfer on theconvenience of the target, and a printer apparatus using the method.

It is still another object of the present invention to provide acommunication control method and apparatus which can realizemulti-channels, and a printer apparatus using the same.

In order to achieve the above object, the present invention comprisesthe following arrangement.

That is, there is provided a communication control method of exchangingdata upon accessing a storage area of an initiator from a target,

-   -   wherein the initiator transmits commands corresponding to read        and write accesses to the storage area to the target so as not        to exceed the number of read and write commands that can be held        by the target, and    -   the target holds the received read and write commands in        different queues, and independently processes the held commands.

There is also provided a communication control method of exchanging dataupon accessing a storage area of an initiator from a target,

-   -   wherein the target checks if a size of data to be transmitted        exceeds a predetermined size, requests the initiator to issue a        write command in the storage area when the size of the data to        be transmitted exceeds the predetermined size, and sends the        data to the initiator when the size of the data to be        transmitted does not exceed the predetermined size, and    -   the initiator issues a write command upon receiving a write        command issuance request from the target.

There is also provided a communication system for exchanging data uponaccessing a storage area of an initiator from a target,

-   -   wherein the initiator transmits commands corresponding to read        and write accesses to the storage area to the target so as not        to exceed the number of read and write commands that can be held        by the target, and    -   the target holds the received read and write commands in        different queues, and independently processes the held commands.

There is also provided a communication system for exchanging data uponaccessing a storage area of an initiator from a target,

-   -   wherein the target checks if a size of data to be transmitted        exceeds a predetermined size, requests the initiator to issue a        write command in the storage area when the size of the data to        be transmitted exceeds the predetermined size, and sends the        data to the initiator when the size of the data to be        transmitted does not exceed the predetermined size, and    -   the initiator issues a write command upon receiving a write        command issuance request from the target.

There is also provided a communication control method of exchanging datawith a target upon accessing a storage area in a memory from the targetconnected via a communication, comprising:

-   -   the queuing step of receiving a spontaneous request from the        target and queuing the request in a queue; and    -   the command generation step of generating and transmitting read        and write commands to the storage area in response to a request        from an application or the target so as not to exceed the number        of read and write commands that can be held by the target.

There is also provided a communication control method of exchanging datawith an initiator upon accessing a storage area of the initiatorconnected via a communication, comprising:

-   -   the queuing step of queuing a read command received from the        initiator in a queue having a predetermined size;    -   the queued execution step of picking up and executing a read        command from the queue;    -   the immediate execution step of executing a write command        received from the initiator immediately after reception; and    -   the transfer request step of issuing a data transfer request to        the initiator.

There is also provided a communication control apparatus for exchangingdata with a target via a storage area, comprising:

-   -   means for communicating with a target;    -   a memory including the storage area;    -   queue management means for queuing a spontaneous request from        the target; and    -   command generation means for generating and transmitting read        and write commands with respect to the storage area in response        to a request from an application or the target so as not to        exceed the number of read and write commands that can be held by        the target.

There is also provided a communication control apparatus for exchangingdata with an initiator by accessing a storage area of the initiator,comprising:

-   -   means for communicating with the initiator;    -   a queue which holds a read command received from the initiator        and has a predetermined size;    -   queued execution means for picking up and executing the read        command from the queue;    -   immediate execution means for executing a write command received        from the initiator immediately after reception; and    -   transfer request means for issuing a data transfer request to        the initiator.

There is also provided a computer readable storage medium, which storesa communication control program for exchanging data by accessing astorage area from a target via a communication, the program comprising:

-   -   queue management means for queuing a spontaneous request from        the target; and    -   command generation means for generating and transmitting read        and write commands with respect to the storage area in response        to a request from an application or the target so as not to        exceed the number of read and write commands that can be held by        the target.

There is also provided a computer readable storage medium, which storesa communication control program for exchanging data by accessing astorage area of an initiator connected via a communication, the programcomprising:

-   -   queue management means for queuing a read command received from        the initiator in a queue having a predetermined capacity;    -   queued execution means for picking up and executing the read        command from the queue;    -   immediate execution means for executing a write command received        from the initiator immediately after reception; and    -   transfer request means for issuing a data transfer request to        the initiator.

There is also provided a printing system using a communication controlmethod in which an initiator transmits commands corresponding to readand write accesses to a storage area to a target so as not to exceed thenumber of read and write commands that can be held by the target, andthe target holds the received read and write commands in differentqueues, and independently processes the held commands, wherein a hostapparatus serving as an initiator is connected to a printer apparatusserving as a target, the printer apparatus receives print data from thehost apparatus and prints out based on the received print data, and thehost apparatus receives status information of the printer apparatus.

There is also provided a printing control apparatus for transmittingprint data to a target, and receiving status information from thetarget, in a communication control method which comprises the queuingstep of receiving a spontaneous request from the target and queuing therequest in a queue, and the command generation step of generating andtransmitting read and write commands to the storage area in response toa request from an application or the target so as not to exceed thenumber of read and write commands that can be held by the target.

There is also provided a printing apparatus for receiving print datafrom an initiator, and transmitting status information to the initiator,by a communication control method which comprises the queuing step ofqueuing a read command received from the initiator in a queue having apredetermined size, the queued execution step of picking up andexecuting a read command from the queue, the immediate execution step ofexecuting a write command received from the initiator immediately afterreception, and the transfer request step of issuing a data transferrequest to the initiator.

Other features and advantages of the present invention will be apparentfrom the following description taken in conjunction with theaccompanying drawings, in which like reference characters designate thesame or similar parts throughout the figures thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of the specification, illustrate embodiments of the invention and,together with the description, serve to explain the principles of theinvention.

FIG. 1 is a block diagram of a target (printer);

FIG. 2 is a block diagram of an initiator (host computer);

FIGS. 3A and 3B show the general format of an ORB;

FIG. 4 shows the format of a QUEUE DEPTH command ORB;

FIG. 5 shows the format of a DATA TRANSFER command ORB;

FIG. 6 shows the format of a REQUESTED READ command ORB;

FIG. 7 shows the format of a DIRECT STATUS RESPONSE command ORB;

FIGS. 8A and 8B show the format of an ACQUIRE DEVICE RESOURCE commandORB;

FIG. 9 shows the format of a data resource release command ORB;

FIG. 10 shows the format of a BASIC DEVICE STATUS command ORB;

FIGS. 11A and 11B show the general format of a status block;

FIG. 12 shows the format of a QUEUE DEPTH status block;

FIG. 13 shows the format of a DATA TRANSFER status block;

FIG. 14 is a flow chart showing the processing procedure executed by theinitiator in response to a generated data transfer request;

FIG. 15 is a flow chart showing the processing procedure executed by afetch agent of the target upon write in a DOORBELL register;

FIG. 16 is a flow chart showing the processing procedure executed by anexecution agent upon reception of an ORB message from the fetch agent;

FIG. 17 is a flow chart showing the processing procedure executed by thetarget in response to a generated data transfer request;

FIG. 18 is a flow chart showing the processing procedure executed by theinitiator upon write in a status register;

FIG. 19 shows the data transfer sequence from the initiator (hostcomputer) to the target (printer);

FIG. 20 shows the sequence upon data transfer from the target to theinitiator using READ REQUEST status;

FIG. 21 shows the sequence upon data transfer from the target to theinitiator using DIRECT status;

FIG. 22 is a block diagram of a target that provides multi-channels;

FIG. 23 is a block diagram of an initiator that provides multi-channels;

FIG. 24 shows the format of a multi-channeled DATA TRANSFER command ORB;

FIG. 25 shows the format of a multi-channeled REQUESTED READ commandORB;

FIG. 26 shows the format of a multi-channeled DIRECT STATUS RESPONSEcommand ORB;

FIGS. 27A and 27B show the format of a multi-channeled ACQUIRE DEVICERESOURCE command ORB;

FIG. 28 shows the format of a multi-channeled RELEASE DEVICE RESOURCEcommand ORB;

FIG. 29 shows the format of a multi-channeled ABDICATE DEVICE RESOURCERESPONSE command ORB;

FIG. 30 shows the format of a multi-channeled BASIC DEVICE STATUScommand ORB;

FIGS. 31A and 31B show the format of an OPEN CHANNEL REQUEST response;

FIGS. 32A and 32B show the format of a CLOSE CHANNEL REQUEST response;

FIGS. 33A to 33C show the general format of a multi-channeled statusblock;

FIG. 34 shows the format of a multi-channeled DATA TRANSFER statusblock;

FIG. 35 shows the format of a multi-channeled DIRECT status block;

FIG. 36 shows the format of a multi-channeled DEVICE RESOURCE ACQUIREstatus block;

FIG. 37 shows the format of a multi-channeled ABDICATE DEVICE RESOURCEstatus block;

FIG. 38 shows the format of a multi-channeled BASIC DEVICE status block;

FIG. 39A is a flow chart showing the processing procedure executed bythe multi-channeled initiator upon write in a status register;

FIG. 39B is a flow chart showing the processing procedure executed bythe multi-channeled target upon write in a DOORBELL register; and

FIG. 40 is a block diagram showing the hardware arrangement of a printersystem using an IEEE1394 interface.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS First Embodiment

A printing system which connects a host computer and printer viaIEEE1394 will be described below as the first embodiment of the presentinvention. In this system, data transfer is done in accordance with aprotocol according to the present invention (to be referred to as HPThereinafter), which uses SBP-2 built on IEEE1394. FIG. 40 shows thehardware arrangement in that printing system.

<Hardware Arrangement of System>

In FIG. 40, a host computer 200 comprises a CPU 1 that processesdocuments including figures, images, characters, tables (containingtable calculations and the like), and so forth on the basis of adocument processing program stored in a program ROM area in a ROM 3. TheCPU 1 systematically controls the respective devices connected to asystem bus 4. The program ROM area of the ROM 3 stores a control programfor the CPU 1 and the like, a font ROM area of the ROM 3 stores fontdata and the like used in the document processing, and a data ROM areaof the ROM 3 stores various data used upon executing the documentprocessing and the like. A RAM 2 serves as a main memory, work area, andthe like of the CPU 1. Programs may be stored in the RAM 2. On the RAM2, a transmission data buffer and a system memory for storing ORBs areassured.

A keyboard controller (KBC) 5 controls key inputs from a keyboard 9 anda pointing device (not shown). A CRT controller (CRTC) 6 controlsdisplay on a CRT display (CRT) 10. A memory controller (MC) 7 controlsaccesses to an external memory 11 such as a hard disk (HD), floppy disk(FD), and the like that store a boot program, various applicationprograms, font data, user file, edit file, and so forth. A 1394interface 8 is connected to a printer 100 according to the IEEE1394standard, and implements communication control with the printer 100.Note that the CPU 1, for example, maps (rasterizes) outline font dataonto a display information RAM area allocated on the RAM 2 to realize aWYSIWYG environment on the CRT 10. The CPU 1 opens various registeredwindows on the basis of commands designated by a mouse cursor (notshown) or the like, and executes various kinds of data processing.

In the printer 100, a printer CPU 12 systematically controls accesses tovarious devices connected to a system bus 15 on the basis of a controlprogram stored in a program ROM area of a ROM 13 or a control programstored in an external memory 14, and outputs an image signal as outputinformation to a printer unit (printer engine) 17 connected via aprinter unit interface 16. The program ROM area of the ROM 13 alsostores a control program for the CPU 12, that implements various agents(to be described later). A font ROM area of the ROM 13 stores font dataand the like used upon generating the output information, and a data ROMarea of the ROM 13 stores information and the like used on the hostcomputer in case of the printer which has no external memory 14 such asa hard disk or the like. The CPU 12 can communicate with the hostcomputer via a 1394 interface 18, and can inform the host computer 200of information and the like in the printer.

A RAM 19 serves as a main memory, work area, and the like of the CPU 12,and its memory capacity can be expanded using an option RAM connected toan expansion port (not shown). Note that the RAM 19 is used as an outputinformation mapping area, environment data storage area, NVRAM, and thelike.

A memory controller (MC) 20 controls accesses to the above-mentionedexternal memory 14 such as a hard disk (HD), IC card, or the like. Theexternal memory 14 is connected as an option, and stores font data,emulation program, form data, and the like. A control panel (console)1002 is provided with operation switches, LED indicators, and the like.The number of external memories is not limited to one, and the printermay comprise more than one external memories, so that a plurality ofexternal memories including an option font card including option fontsin addition to internal fonts, an external memory that stores programsfor interpreting other printer control languages, and the like may beconnected. Furthermore, an NVRAM (not shown) may be added, and may storeprinter mode setup information from the control panel 1002.

<Arrangement of Initiator>

FIGS. 1 and 2 show a communication system which uses the printer 100 asa target, and the host computer 200 as an initiator in theabove-mentioned hardware arrangement. In this embodiment, sucharrangements are implemented when the CPUs in the host computer andprinter execute predetermined programs. The initiator shown in FIG. 2will be described first.

In FIG. 2, in the host computer serving as the initiator, a printerdriver 209 as an application issues a data transfer request to a printervia an HPT processor 203, and receives a response (reply) from theprinter.

The HPT processor 203 includes an ORB manager 206. The ORB manager 206manages ORBs generated in a system memory 208. An ORB is a block thatstores the address, size, and the like of a data buffer to betransferred from the host computer to the printer and vice versa. ORBsare linked in turn to form an ORB list. For these ORBs, the followingprocessing rules are defined:

(1) ORBs in the ORB list are processed in turn in the FIFO order. Uponreception of a completion message (status block), the corresponding ORBis deleted from the ORB list.

(2) A newly generated ORB is added to the end of the ORB list.

(3) The maximum number of ORBs that can be linked to the ORB list is thesame as the total capacity of two queues in the printer, as will bedescribed later.

In order to implement item (3), the ORB manager 206 prepares twocounters in correspondence with the two queues of the printer. Onecounter is named CurrentQuedQUE, and indicates the current number ofempty positions in the prefetch queue (to be described later) in theprinter. The other counter is named CurrentImmediateQUE. The queuecapacity corresponding to this counter is 1 in this embodiment, and onlyan entry which is being processed can be queued. The contents of thesecounters are incremented/decremented in correspondence withgeneration/deletion of ORBs.

When the host computer generates an ORB, it writes an arbitrary value ina register called a DOORBELL register to inform the printer ofgeneration of an ORB. This procedure is specified in SBP-2, and isdescribed in its manual or the like.

The HPT processor 203 includes a status queue 204 and queue processor205. Status received via the 1394 interface is identified by a statusidentifier 202, and is directly sent to the ORB manager 206 or is addedto the status queue 204 depending on the type of status. The statusappended to the status queue 204 is processed by the queue processor 205in the FIFO order. There are two types of status.

(1) Normal status . . . This status is a status block that notifies thedata transfer result between the host computer and printer, and isdirectly sent to the ORB manager 206.

(2) Unsolicited status . . . This status is a status block indicatingthat asynchronous data to be transferred from the printer to the hostcomputer has been generated, and is added to the status queue 204.Normally, this status is spontaneously issued by the printer.

These status types are discriminated by values written in status blocks.

A status register 210 is a register in which the printer writes data toindicate the presence of data to be read by the host computer.

The host computer serving as the initiator has the aforementionedfunctional arrangement.

<Arrangement of Target>

FIG. 1 is a block diagram showing the functional arrangement of theprinter serving as the target.

In FIG. 1, a DOORBELL register 108 is a register in which the hostcomputer writes data. Writing an arbitrary value in the DOORBELLregister means generation of a new ORB. A command fetch agent 103 readsan ORB via a 1394 interface 101, and appends the read ORB to a prefetchqueue 104 or sends it to an immediate execution agent 106 depending onits type. The type of command is determined with reference to a fieldindicating immediate or queued execution. However, in practice, thisfield corresponds to the function of command. For example, in thisembodiment, a command for data transfer from the target to the initiator(REQUESTED READ command) and a command for capturing the target stateare immediate execution commands, and a command for transferring printdata from the initiator to the target or the like is a queued executioncommand.

A queued execution agent 105 and the immediate execution agent 106 readdata from a buffer of the host computer or write data supplied from adata processor 107 in accordance with the contents of an ORB read by thecommand fetch agent 103. After that, these agents return normal statusto the host computer.

Furthermore, the immediate execution agent 106 sends unsolicited statusto the host computer in response to a data transfer request from thedata processor 107 which performs rasterization for generating rasterdata by interpreting and executing PDL, and device management. A businterface 102 is used for accessing a desired memory location on thesystem memory 208 of the host computer 200 from the printer 100.

In the system of this embodiment, the queued execution agent is used fordata transfer ORBs from the host computer to the printer, and theimmediate execution agent is used for data transfer ORBs from theprinter to the host computer.

The arrangements and operations of the initiator and target have beenbriefly explained. Prior to a detailed description thereof, the contentsof an ORB will be explained in detail below.

<Contents of Command ORB (Operation Request Block)>

FIGS. 3A and 3B show the general format of an ORB. In FIG. 3A, a“Next_ORB” (link) field 301 stores a link to the next ORB. If there isno next ORB, a predetermined value indicating it is stored. Note thatthe first ORB is indicated by a predetermined address register. A“data_descriptor” (data address) field 302 indicates address in the databuffer. A “d” (direction) field 303 indicates data transfer (0: write)from the host computer to the printer or data transfer (1: read) fromthe printer to the host computer. A “data_size” (data size) field 304indicates the size of the data buffer indicated by the address field302. These “Next_ORB” field 301 to “data_size” field 304 are thosespecified in SBP-2, and fields 305 to 308 to be described below are usedin processing unique to HPT.

An “i” field (immediate bit) 305 indicates whether that ORB is to beexecuted by the immediate or queued execution agent in the target. Ifthe value in that field is “0”, i.e., the queued execution agent, theORB is placed in the prefetch queue; if the value is “1”, the ORB isprocessed by the immediate execution agent. A “function” (function)field 306 indicates the meaning of the ORB, as shown in FIG. 3B. Thiswill be described in detail later. A “command_block_length” (commandlength) field 307 indicates the length of a “control_block” (controlblock) field 308. The control block field 308 stores various values incorrespondence with the value in the function field 306.

The contents of an ORB will be explained in units of functions.

(QUEUE DEPTH Command)

FIG. 4 shows a QUEUE DEPTH command ORB of function=0. This command isused for obtaining the depth of the prefetch queue 104 of the target.The immediate bit is set at “1”.

A control block of this command includes two fields, i.e., a “source_ID”(source ID) field 401 and “status_queue_depth” (status queue depth)field 402. The source ID field stores the identifier of a process thathas logged in the initiator. In the example shown in FIG. 2, thelogged-in process is the printer driver. This field is added to allowthe target to identify the process to respond when a plurality ofprocesses have been logged in. The status queue depth field 402 informsthe target of the depth of the status queue 204 of the initiator.

The status queue depth field is used for managing the number ofunsolicited status blocks queued in the status queue in the target. Thetarget manages the depth of the status queue in accordance with thegeneration/processing completion message of unsolicited status in thesame manner as management of the prefetch queue by the initiator.

Upon reception of the QUEUE DEPTH command, the target stores the statusqueue length in a counter CurrentUnsolicitedQUE, and returns theprefetch queue length to the initiator. The initiator manages the numberof ORBs queued in the target in correspondence with generation anddeletion of ORBs on the basis of the queue depth of the prefetch queueobtained by this command.

(DATA TRANSFER Command)

FIG. 5 shows a DATA TRANSFER command of function 1. This command is usedupon transferring data from the initiator to the target. A“page_table_present” bit 501 indicates the presence of a page table.When a page table is present, the page size to be referred to by thepage table is set in a “page_size” field 502. The data buffer to betransferred is indicated by this page table, an address 503, and a datasize 504.

Upon reception of the DATA TRANSFER command, the target writes data inthe designated data buffer or reads out data therefrom in accordancewith the value in a direction field.

(REQUESTED READ Command)

FIG. 6 shows a REQUESTED READ command of function=2. This commandsprovides a data buffer in which data is to be written to the printerwhen “READ REQUEST status”, i.e., a data transfer request from theprinter as the target to the host is sent from the target. A“Sequence_number” (sequence number) field 601 is set with the same valueas the sequence number appended to the corresponding READ REQUESTstatus, which instigated issuance of this command. This value is anumber which makes REQUESTED READ status and REQUESTED READ commandcorrespond to each other. The format of other fields is the same as thatin the DATA TRANSFER command. In this command, the immediate bit is setat “1”, and the direction bit is also set at “1” (read). The reason whythe immediate bit is set at “1” is to immediately respond to READREQUEST status issued by the target. The buffer size uses a valuedesignated by READ REQUEST status.

Upon reception of the DATA TRANSFER command, the target writes data inthe designated data buffer assured on the system memory of theinitiator.

(DIRECT STATUS RESPONSE Command)

FIG. 7 shows a DIRECT STATUS RESPONSE command ORB of function=3. Thiscommand is issued in response to READ REQUEST status when the initiatormakes the target abdicate a read request. Alternatively, this command isused as a reply to the target in response to DIRECT status from thetarget. A “sequence_number” (sequence number) field 701 is set with thesame value as the sequence number appended to the corresponding READREQUEST status or DIRECT status, which instigated issuance of thiscommand. The format of other fields is the same as that in the DATATRANSFER command. In this command, the immediate bit is set at “1”.

Upon reception of the DIRECT STATUS RESPONSE command, the targetabdicates a read request if it has issued the READ REQUEST status havingthe corresponding sequence number.

(ACQUIRE DEVICE RESOURCE Command)

FIG. 8A shows an ACQUIRE DEVICE RESOURCE command ORB of function=8. Themeaning of a “resource_ID” (resource ID) field 801 is as shown in FIG.8B. “0” is a value that depends on the device class used and logicalunit characteristics. In this system, “0” indicates the printer as adevice class and print service as logical unit characteristics.

Upon receiving this ACQUIRE DEVICE RESOURCE command, the target assignsthe resource designated by the resource ID to the initiator as thesender of this command.

(RELEASE DEVICE RESOURCE Command)

FIG. 9 shows a RELEASE DEVICE RESOURCE command of function=9. Themeaning of a “resource_ID” (resource ID) field 801 is as shown in FIG.8B.

Upon receiving the RELEASE DEVICE RESOURCE command, the target releasesthe resource designated by the resource ID.

(BASIC DEVICE STATUS Command)

FIG. 10 shows a BASIC DEVICE STATUS command ORB of function=A (Hex).

Upon reception of this command, the target replies its own status to theinitiator while encapsulating it in a basic device status block. Byissuing this command, the initiator can recognize the printer status. Inthe printer, for example, various kinds of status information related tothe printer such as the paper size, emulation supported, and the likeare sent back from the target as basic status.

<Contents of Status Block>

FIGS. 11A and 11B show a status block sent back from the printer as thetarget to the host computer as the initiator. A status block is preparedin correspondence with each aforementioned command ORB. The status blockis issued by the queued and immediate execution agents of the target.

In FIG. 11A, the first field to “ORB_offset_lo” field are specified inSBP-2, and include fields for indicating a command ORB corresponding tostatus, and the like. An “i” (immediate bit) field 1101 indicates whichone of the queued and immediate execution agents issued this status. Ifthe value is “0”, it indicates that the status was issued by the queuedexecution agent; if the value is “1”, it indicates that the status wasissued by the immediate execution agent. An “hpt_status” (hpt status)field 1102 indicates the type of status block, as shown in FIG. 11B. An“hpt_status_dependent” field 1103 is given its value depending on hptstatus. A “status_length” (status length) field 1104 indicates thelength of a response block 1105. The status blocks will be explainedbelow in units of types.

(QUEUE DEPTH Status Block)

FIG. 12 shows QUEUE DEPTH status of hpt status=0. The QUEUE DEPTH statusis a reply from the target in response to the QUEUE DEPTH command, andthe target sets the depth of the prefetch queue 104 in a“prefetch_queue_depth” field 1201 and sends back the status to theinitiator. With this status, the initiator can detect the size of theprefetch queue, and manages the number of ORBs generated incorrespondence with the size.

(DATA TRANSFER Status Block)

FIG. 13 shows DATA TRANSFER status of hpt status=1. The DATA TRANSFERstatus is a reply from the target in response to the DATA TRANSFERcommand, and is issued by the target upon completion of processing ofthe DATA TRANSFER command ORB. Upon reception of this status, theinitiator can detect that one ORB has been processed and deleted fromthe queue of the target.

(READ REQUEST Status Block)

This status is hpt status=2 (its format is not shown), and has the databuffer size to be assured by the initiator in a response block.Normally, the target issues this status not in response to the commandORB but spontaneously. The initiator issues the above-mentionedREQUESTED READ command ORB in response to this READ REQUEST status. Theprocedure for this process will be described later.

(DIRECT Status Block)

This status is hpt status=3 (its format is not shown), and includesstatus of application level (i.e., the data processor in the target) ina response block. More specifically, data exchange on the applicationlevel is normally done using the ORB and data buffer linked thereto.However, when data is very small and falls within the upper limit (24bytes in this embodiment) of the response block, an application-levelreply is encapsulated in an HPT-level reply. In response to this status,the initiator issues the DIRECT STATUS RESPONSE command ORB.

(DEVICE RESOURCE ACQUIRE Status Block)

This status is hpt status=8 (its format is not shown), and is issued bythe target that has received the ACQUIRE DEVICE RESOURCE command andprocessed it.

(DEVICE RESOURCE RELEASE Status Block)

This status is hpt status=9 (its format is not shown), and is issued bythe target that has received the RELEASE DEVICE RESOURCE command andprocessed it.

(BASIC DEVICE Status Block)

This status is hpt status=A (Hex) (its format is not shown), and isissued by the target upon reception of the BASIC DEVICE STATUS command.This status is set with predetermined device status.

The commands and status blocks used in the printing system of thisembodiment have been described. The data exchange procedures in theinitiator and target will be explained below.

<Data Transfer Request Processing from Initiator>

FIG. 14 shows the procedure for informing the printer of generation of acommand ORB in response to a data transfer request from the hostcomputer to the printer or vice versa in the host computer.

A data transfer request from an application such as the printer driveror the like is monitored in step S1401. The data transfer request may bethe one that informs the host computer of the presence of data to betransferred directly from an application such as a printer driver or maybe the one that was generated in accordance with a data read requestfrom the printer. Note that status that the printer sends to the hostcomputer asynchronous with the host computer will be referred to asUnsolicited status hereinafter. On the other hand, status which isreturned as a processing completion message of a command ORB from thehost computer will be referred to as normal status hereinafter.

Upon detection of a data transfer request, it is determined in stepS1402 if data transfer is executed by a queued or immediate executioncommand. If data transfer is executed by an immediate execution command,the immediate bit of an ORB is set. When an ORB is issued in response toUnsolicited status from the printer, data transfer is executed by animmediate execution command; when an ORB is issued in response to a datatransfer request from the application of the host computer, datatransfer is executed by a queued execution command.

In case of queued execution, it is checked in step S1403 if the counterCurrentQuedQUE is “0”. Upon power ON or resetting, the depth of theprefetch queue of the printer is read by the QUEUE DEPTH command, and isset as the default value of the counter CurrentQuedQUE. Morespecifically, the counter CurrentQuedQUE counts the current number ofempty positions in the prefetch queue. If it is determined in step S1403that the number of empty positions is “0”, since the prefetch queue ofthe target is not empty, the control waits until the queue has an emptyposition. If an empty position is found, the value of the counterCurrentQuedQUE is decremented by 1 in step S1404, and a data transferORB is generated and is linked to the ORB list in step S1407. Afterthat, an arbitrary value is written in the DOORBELL register 108 of theprinter in step S1408, thus informing the target of generation of a newORB.

On the other hand, if it is determined in step S1402 that data transferis done by an immediate execution command, it is checked in step S1405if the value of the counter CurrentImmediateQUE is larger than “0”. Notethat no queue is prepared for the immediate execution agent of thetarget and, hence, the maximum value of this counter is “1”. Therefore,the counter CurrentImmediateQUE is set at “1” upon resetting. If thevalue of the counter CurrentImmediateQUE is larger than “0”, the valueof the counter is decremented by 1 in step S1406. Then, an ORB is linkedto the ORB list to write a doorbell.

Upon write in the DOORBELL register in this way, the fetch agent fetchesan ORB into the target in the procedure shown in FIG. 15.

<Processing by Fetch Agent>

FIG. 15 shows the processing procedure executed by the fetch agent ofthe target upon write in the DOORBELL register 108.

Upon write in the DOORBELL register 108, the address of the first linkedORB in the system memory is set at a read pointer in step S1601.

In step S1602, the immediate bit of the ORB indicated by the readpointer is tested to check if it is an immediate or queued executioncommand. If the ORB of interest is a queued execution command, the endaddress (NextWritePointer) of the prefetch queue 104 is acquired in stepS1603. Since the host computer writes a doorbell after having confirmedan empty position of the prefetch queue, the queue surely has an emptyposition.

The ORB indicated by the read pointer is copied to the end of theprefetch queue in step S1604, and the fetch agent informs the queuedexecution agent of ORB reception in step S1605. It is then checked instep S1606 if the “Next_ORB” field (link field to the next ORB) of theORB indicated by the read pointer is NULL, i.e., if a linked ORB ispresent. If that field is NULL, the flow ends; otherwise, the address ofthat linked ORB is set at the read pointer to repeat the flow from stepS1602.

On the other hand, if it is determined in step S1602 that the ORB is animmediate execution command, that ORB is copied to the address indicatedby the immediate execution agent in advance in step S1608. After that,the fetch agent informs the immediate execution agent of ORB receptionin step S1609, and the flow advances to step S1606.

In this manner, the ORB is fetched into the target to inform eachexecution agent of ORB reception. Then, the ORB is processed by theprocedure shown in FIG. 16.

<Processing by Execution Agent>

There are two types of execution agents, i.e., the immediate and queuedexecution agents, but they process ORBs by the same procedure. Hence,their processing will be described simultaneously using FIG. 16.

When the execution agent is informed of ORB reception from the fetchagent, it extracts the values of the data address field, direction bit,and data size field of the ORB indicated by Nextreadpointer in stepS1701. Note that Nextreadpointer is a pointer which is stored in thequeue and indicates the ORB that the execution agent is about toprocess. This pointer indicates the first ORB in the prefetch queue incase of the queued execution agent.

It is checked in step S1702 if the extracted data size is “0”. If thesize is not “0”, it is checked in step S1703 if the direction bit(Direction bit) indicates a write or read. If the direction bitindicates a write, the execution agent reads out data designated by thedata address and size from the system memory of the initiator and passesthe readout data to the data processor 107 in step S1704.

The data processor processes the passed data in steps S1705 to S1707.For example, PDL data is interpreted and rasterized in case of theprinter. In step S1707, the execution agent is informed of the end ofprocessing.

Upon informing of the end of processing in the data processor, theexecution agent generates a DATA TRANSFER status block (normal status)as a message indicating the end of processing of the ORB of interest instep S1708, and writes that message in the status register 210 to informthe initiator of the status in step S1709.

On the other hand, if it is determined in step S1703 that the directionbit of the ORB indicates a read, the execution agent writes data in adata buffer designated by the data address field and data size field ofthe ORB in step S1710. The data written by the target is called reversedata. The reverse data to be written has been generated by the dataprocessor 107 or the like and stored in a buffer. For example, thereverse data is data of more than 24 bytes such as a built-in font listof the printer.

In step S1711, the buffer that stored the data which has been written isreleased.

Upon completion of processing, the execution agent generates a statusblock (normal status) of a processing completion message in step S1713,and writes a predetermined value in the status register to inform thehost computer of the status block message in step S1714.

Lastly, in step S1715, the execution agent increments the value of thecounter CurrentUnSolicitedQUE by 1. Upon reception of a QUEUE DEPTHcommand, the value stored in its “status_que_depth” field is set as thedefault value of the counter CurrentUnSolicitedQUE. The contents of thiscounter are incremented/decremented in correspondence with transmissionof an Unsolicited status block and its processing completion message toindicate the number of empty positions of the status queue 204. Thecounter CurrentUnsolicitedQUE is counted under the following condition:

—Count-Down Condition

(1) Upon transmission of an Unsolicited status block, the counter isdecremented by 1. In the initiator, unsolicited status alone is queuedin the status queue 204.

—Count-Up Condition

(1) Upon transmission of a processing completion status block of aREQUESTED READ ORB, the counter is incremented by 1. Upon reception ofthis status, the initiator removes the processed status block from thestatus queue 204.

(2) Upon transmission of a processing completion status block for an ORBwith the data size=0, the counter is incremented by 1. In other words,upon transmission of a status block for a DIRECT STATUS RESPONSE ORB,the counter is incremented by 1. Upon reception of this status, theinitiator removes the processed status block (direct status) from thestatus queue 204.

If it is determined in step S1702 that the data size is “0”, since thereis no data to be processed, the execution agent returns a status blockwithout any processing to send a processing completion message in stepS1713.

With the aforementioned procedures, generation of an ORB by theinitiator, and its processing and generation of a status block by thetarget are done. Data transfer in response to Unsolicited statustransmitted from the printer to the host computer will be explainedbelow with reference to FIGS. 17 and 18.

<Issuance of Unsolicited Status in Target>

Some kinds of information must be immediately informed from the printerto the host computer, for example, when errors such as out-of-paper,jam, and the like have occurred in the printer. In such case, theprinter spontaneously transfers data to the host computer asynchronouslywith commands from the host computer. If data to be sent from theprinter is generated, the data processor informs the immediate executionagent of the presence of such data, thus starting the processing in FIG.17.

It is checked in step S1801 if the data to be transmitted to the hostcomputer exceeds 24 bytes. Note that 24 bytes are the upper limit of thedata volume that can be stored in the response block of the statusblock.

If the data exceeds the upper limit value, a READ REQUEST status block(Unsolicited status) is generated in step S1802, and the storage addressof reverse data is set in the “ORB_offset” field of that status block instep S1803. At this time, the size of the reverse data is also writtenin the status block.

It is checked in step S1804 if the value of the counterCurrentUnsolicitedQUE is larger than “0”, i.e., the status queue has anempty position. If NO in step S1804, after the control waits until thequeue has an empty position, the value of the counterCurrentUnsolicitedQUE is decremented by 1 in step S1805, and anappropriate value is written in the status register in step S1806.

On the other hand, if the data is equal to or smaller than 24 bytes,since that data can be sent to the host computer while beingencapsulated in the status block, DIRECT status (Unsolicited status) isgenerated, and reverse data is stored in its Command set dependentfield. After that, the flow branches to step S1804.

In this fashion, the Unsolicited status is sent to the initiator.

Upon reception of the status, the initiator processes it by theprocedure shown in FIG. 18.

<Status Processing by Initiator>

This processing is started by an interrupt that is produced upon settinga predetermined value in the status register. Multiple interrupts arepermitted; an interrupt is generated every time the value is set in thestatus register.

In step S1501, it is checked if status is normal or Unsolicited status.If the status is Unsolicited status, the status block is read out fromthe target, and is copied to the end of the status queue in step S1502.It is checked in step S1503 if the block of interest has moved to thehead position of the queue. If YES in step S1503, a buffer for storingreverse data is assured in step S1504, and it is checked in step S1505if the status is READ REQUEST or DIRECT status.

If the status is READ REQUEST status, a REQUESTED READ command ORB isgenerated in step S1506. The generated ORB is set with the “immediate”flag, and its direction flag indicates a read. Also, the address of thebuffer that stores data to be read out is written in the ORB. Afterthat, the process shown in FIG. 14 is informed that an event whichrequires data transfer has taken place in step S1507. The process shownin FIG. 14 sends the ORB generated in step S1506 to the target, and thedata from the target is written in the data buffer, thus attaining datatransfer.

If it is determined in step S1505 that the status is DIRECT status,reverse data in that status is copied to the assured buffer in stepS1508, and is passed to a host process such as an application or thelike in step S1509. After that, a DIRECT STATUS RESPONSE ORB (immediatebit is set at “immediate”) is generated in step S1510. At this time, thedata size=0 is designated.

On the other hand, if it is determined in step S1501 that the status isnormal status, it is checked in step S1511 if the direction bit of theORB corresponding to that status indicates a read or write. If thedirection bit indicates a write, i.e., data transfer from the initiatorto the target, the corresponding ORB is deleted from the list (stepS1512), the data buffer used by that ORB is released (step S1513), andthe value of the counter CurrentQuedQUE indicating the empty size of theprefetch queue is incremented by 1 (S1514).

On the other hand, if the direction bit indicates a read, i.e., datatransfer from the target to the initiator, since that status is a replyto the REQUESTED READ COMMAND ORB, a host process such as a printerdriver or the like is informed of the end of read in step S1515. Thecorresponding ORB is deleted from the list in step S1516, and the valueof the counter CurrentImmediateQUE is incremented by 1. That is, theimmediate execution agent is ready to send the next ORB.

In this fashion, upon write in the status register, the initiatorprocesses the status. That is, Unsolicited status is queued and isprocessed in turn, but normal status is processed immediately. Thereason why the Unsolicited status is queued is that it generates an ORB.The number of ORBs generated and linked to the ORB list is limited belowthe total of the processing capacity of the execution agents of thetarget and the size of the prefetch queue. The number of ORBs is limitedin such way to guarantee that the ORB to be immediately executed isprocessed immediately after an ORB generation message. The immediateexecution command is immediately processed by the immediate executionagent as long as it is passed to the target. However, if ORBs aregenerated freely, the ORB list itself unwantedly becomes a queue of ORBsto be processed by the immediate execution agent, and the generated ORBis not passed to the target. As a result, immediate execution is notguaranteed. Since the number of ORBs linked is limited to the totalvalue of the number of ORBs placed in the prefetch queue of the target,and the number of ORBs which are being executed by the execution agents,an ORB generated by the initiator can be immediately passed to thetarget. For this reason, even upon reception of Unsolicited status, theinitiator cannot often generate a new ORB due to the limitation on thenumber of ORBs. Hence, the Unsolicited status is temporarily placed inthe status queue.

<Example of Message Sequence>

An example of the message sequence exchanged between the initiator andtarget in the above-mentioned procedures will be explained below withreference to FIGS. 19 to 21.

(Data Transfer Sequence to Target)

FIG. 19 shows an example of the sequence upon data transfer from theinitiator (host computer) to the target (printer).

Note that SBP-2 in FIG. 19 represents data specified by the SBP-2standard, i.e., the processing layer that processes the fields specifiedin SBP-2 in the command shown in FIGS. 3A and 3B and status shown inFIGS. 11A and 11B. Also, HPT represents the processing layer thatperforms processing defined in units of functions, which are notspecified in SBP-2. HPT executes the procedures of the above-mentionedflow charts. SBP-2 implements functions of linking ORBs, writing adoorbell, passing an ORB or status to HPT, and the like.

An application on the initiator generates data and its HPT generates anORB (in this case, data transfer ORB), the value of the empty queuecounter (CurrentQuedQUE) is decremented by 1, and an ORB link request isissued to SBP-2 (1901). SBP-2 links the generated ORB to the list, andissues a write request to the DOORBELL register (1902). The 1394interface writes a doorbell in the DOORBELL register (1903), and SBP-2of the target then receives that message (1904).

Upon reception of the message, SBP-2 issues an ORB read request to the1394 interface (1905), and the ORB is read out from the system memory(1906). HPT stores the readout ORB in the corresponding queue incorrespondence with its contents (1907). In this case, since the ORB isa data transfer command ORB, a data read request is issued to the 1394interface (1908). In response to this request, data is read out from thedesignated address and is passed to an application (1909). Theapplication in this case is, e.g., a rasterizer for mapping an image,and the mapped image is printed out by the printer engine.

After the data is read out, a status block transmission request isissued to SBP-2 of the target (1910), and a status block (data transferstatus) is sent back to the initiator (1911). Upon reception of thestatus, HPT of the initiator deletes the corresponding ORB from thelink, and increments the empty queue counter (CurrentQuedQUE) by 1(1912).

With the above-mentioned sequence, data is transferred from theinitiator to the target.

(Data Transfer Sequence to Initiator)

FIG. 20 shows the READ REQUEST status sequence.

When an application on the target generates data, Unsolicited status(READ REQUEST status) is generated, the status queue counter(CurrentUnsolicitedQUE) is decremented by 1, and an Unsolicited statustransmission request is issued (2001). Upon reception of this request,SBP-2 transmits an Unsolicited status block to the initiator (2002) Uponreception of this status, the SBP-2 layer of the initiator transmits anUnsolicited status block to the HPT layer (2003). The HPT layer copiesthe Unsolicited status block to the status queue.

For the status at the head position of the status queue, the HPT layerprepares a data buffer and read request ORB and requests the SBP-2 layerto link the generated ORB (2004). The SBP-2 layer issues a write requestto the DOORBELL register (2005), and the 1394 interface writes adoorbell (2006). A doorbell write message is sent from the 1394interface to SBP-2 (2007), and issuance of a read request of the ORB(2008) and read of the ORB (2009) are immediately done. The readout ORBis passed to the HPT layer of the target, and the HPT layer stores thatORB in the designated queue (2010). After that, the HPT layer interpretsthe contents of the ORB to recognize a data read request, and issues thedata write request to the 1394 interface (2011).

In response to this request, reverse data is written in the data bufferprepared by the initiator (2012).

Upon completion of this processing, the target issues a status blockgeneration request, and increments the number of empty positions of thestatus queue by 1 (2013). In response to the request, a normal statusblock is sent back to the initiator (2014). When an ORB link deletionrequest is issued to HPT in response to that status, the correspondingORB is deleted, and the number of empty positions (must be 0) of thequeue of the immediate execution agent is incremented by 1, thusreleasing the used data buffer (2015).

With this sequence, data is transferred from the target to theinitiator.

(Data Transfer Sequence to Initiator)

FIG. 21 shows the sequence upon data transfer from the target to theinitiator. Unlike in the sequence of FIG. 20, since the data to betransferred is small, DIRECT status is used.

When an application on the target generates data, Unsolicited status(DIRECT status) is generated, the status queue counter(CurrentUnsolicitedQUE) is decremented by 1, and an Unsolicited statustransmission request is issued (2101). Upon reception of this request,SBP-2 transmits an Unsolicited status block to the initiator (2102).Upon reception of this status, the SBP-2 layer of the initiatortransmits an Unsolicited status block to the HPT layer (2103). The HPTlayer copies the Unsolicited status block to the status queue.

For the status at the head position of the status queue, the HPT layerreads out data on the application level encapsulated in that status,prepares a data buffer and DIRECT STATUS RESPONSE ORB, and requests theSBP-2 layer to link the generated ORB (2104). The SBP-2 layer issues awrite request to the DOORBELL register (2105), and the 1394 interfacewrites a doorbell (2106). A doorbell write message is sent from the 1394interface to SBP-2 (2107), and issuance of a read request of the ORB(2108) and read of the ORB (2109) are immediately done.

The readout ORB is passed to the HPT layer of the target, and the HPTlayer stores it in the designated queue (2110). After that, the HPTlayer interprets the contents of the ORB. If it is confirmed that theORB is a DIRECT STATUS RESPONSE ORB, the target issues a correspondingstatus block generation request, and increments the number of emptypositions of the status queue by 1 (2111). In response to this request,a normal status block is sent back to the initiator (2112). When an ORBlink deletion request is issued to HPT in response to that status, thecorresponding ORB is deleted, and the number of empty positions of thequeue of the immediate execution agent is incremented by 1, thusreleasing the used data buffer (2113).

With this sequence, data is transferred from the target to theinitiator. In this sequence, two steps, i.e., a data write request(2011) and write of reverse data (2012), are omitted as compared to thatshown in FIG. 20.

<Functions Unique to This System>

The arrangement and operation of this system are as has been describedabove. The functions, arrangement, merits, and the like unique to thissystem are summarized below:

(1) Two execution agents, i.e., queued and immediate execution agentsare prepared in the target, and command queues are provided incorrespondence with these execution agents. In this way, data transferrequest ORBs from the initiator are queued and processed in turn (queuedexecution), but READ REQUEST status from the target is processedimmediately after a corresponding (REQUESTED READ ORB) is issued(immediate execution). The immediate execution is guaranteed since theupper limit of the number of ORBs linked to the ORB list is limited tothe size of the queued execution queue for write ORBs, and is limited tothe size (1 in this case) of the immediate execution queue for readORBs.

On the other hand, READ REQUEST status from the target is queued in theinitiator. For this reason, a data transfer request from the initiatoris appended to the prefetch queue, and a data transfer request (readrequest) from the target is added to the status queue. With thiscontrol, full-duplex communication channels can be provided between theapplications on the initiator and target. That is, irrespective of thedata transfer direction, requests appended to the queues are processedin the FIFO order, and data transfer in one direction does not influencethat in the other direction, thus providing independent channels whichdo not interfere with each other. In other words, data generated in theinitiator or target can be asynchronously transferred from the initiatorto the target or vice versa.

(2) Since the initiator and target monitor the empty sizes of eachothers' queues, the transmitted ORB or status block is reliablyreceived.

(3) Full-duplex communication channels are provided by a single loginprocess. That is, since data can be exchanged using the computer withmany resources as the initiator and the printer with poor resources asthe target, the resources of the printer, especially, the requiredmemory capacity, can be suppressed.

(4) Since the IEEE1394 interface is used, data transfer to the targetcan be done when the target reads out data as its resources becomeavailable, and the initiator can be prevented from being occupied bydata transfer on the convenience of the target. If the printer serves asthe target, it can read out data passed from the computer as itsresources become available. For this reason, the host computer need notexecute processing for monitoring the printer and starting data transferafter it confirms that the printer is ready to receive data. That is,the host computer can send data to the printer irrespective of theprinter state, and need not transfer data after the printer becomesavailable.

(5) Since SBP-2 is used, an ORB alone is queued in the target, and datato be transferred itself is stored in the initiator in the processingwait time. For this reason, the memory resources of the target can beminimized.

(6) Using DIRECT status, data of the application layer can beencapsulated in status of the HPT layer, and can be transmitted from thetarget to the initiator. For this reason, the data transfer sequence canbe shortened.

Note that the system of this embodiment is not limited to the hostcomputer and printer, but may be applied to various other apparatuses.The above-mentioned features are effective not only for the relationshipbetween a host computer and printer, but also for connections between ahost computer and a peripheral apparatus with small resources, andbetween peripheral apparatuses.

Second Embodiment

A system that simultaneously provides a plurality of logical channelswill be explained as the second embodiment of the present invention. Inthis case, on the target side, a digital multi-functional machine thatcombines a printer, facsimile, and image scanner can be used in place ofthe printer alone.

<System Arrangement>

FIG. 23 is a block diagram of an initiator of this embodiment. In FIG.23, only the differences from FIG. 2 will be explained, and adescription of the common components will be omitted. The characteristicfeatures of FIG. 23 are that a status identifier 212 identifies not onlythe type of status but also logical channels and distributes statusblocks in units of channels, and has an arrangement with a system memoryand HPT processor per channel for a plurality of (2 in FIG. 23)channels.

Note that the status identifier 212 identifies a channel in accordancewith the channel ID included in a status block. This will be describedlater. For example, when a digital multi-functional machine is used,different applications may be assigned in units of channels, i.e., onechannel is used by a printer driver and the other channel by an imagescanner driver, or a single application may use a plurality of channels.

FIG. 22 is a block diagram of a target. The difference from FIG. 1 liesin that a command fetch agent 113 distributes command ORBs in units ofchannels. Each channel has the same arrangement as that in FIG. 1, andhas a prefetch queue and two execution agents (queued and immediateexecution agents).

Note that an ORB indicates a logical channel, and the command fetchagent identifies a channel with reference to it.

<Format of Command ORB>

FIGS. 24 to 32B show examples of the formats of command ORBs. FIG. 24shows a data transfer command ORB, FIG. 25 shows a REQUESTED READcommand ORB, FIG. 26 shows a DIRECT STATUS RESPONSE command ORB, FIGS.27A and 27B show an ACQUIRE DEVICE RESOURCE command ORB, FIG. 28 shows aRELEASE DEVICE RESOURCE command ORB, and FIG. 30 shows a BASIC DEVICESTATUS command ORB. These command ORBs are substantially the same asthose in the first embodiment, except that they have channel ID fields.

FIG. 29 shows an ABDICATE DEVICE RESOURCE RESPONSE command ORB, which isa response to an ABDICATE DEVICE RESOURCE request from the target. Sincethe target has poor resources, the resources of processes may becomeshort when a plurality of channels are used and when a plurality ofapplication processes are running. In such case, the target issues theABDICATE DEVICE RESOURCE request.

FIG. 31A shows an OPEN CHANNEL REQUEST command used for issuing achannel open request, and FIG. 31B shows OPEN CHANNEL REQUEST statuscorresponding to that command. With these command and status, a desiredlogical channel is opened.

FIG. 32A shows a CLOSE CHANNEL REQUEST command used for issuing achannel close request, and FIG. 32B shows CLOSE CHANNEL REQUEST statuscorresponding to that command. With these command and status, a desiredlogical channel is closed.

<Format of Status Block>

FIGS. 33A to 38 show the formats of status blocks. FIGS. 33A to 33C showthe general format of status, FIG. 34 shows READ REQUEST status, FIG. 35shows DIRECT status, FIG. 36 shows ACQUIRE DEVICE RESOURCE status, andFIG. 38 shows BASIC DEVICE status. The formats of these status blocksare substantially the same as those of the first embodiment, except thatthey include channel IDs.

FIG. 37 shows an ABDICATE DEVICE RESOURCE status block, which stores aresource ID, which is used for requesting the initiator to abdicate, ina resource ID field 3701. Since this status is a request issued by thetarget, it is transmitted as Unsolicited status to the initiator.

<Command/Status Processing Procedure in Initiator and Target>

FIGS. 39A and 39B show the processing procedures in the initiator andtarget of this embodiment. FIG. 39A shows the processing procedurestarted upon write in a status register in the initiator, andcorresponds to FIG. 18 of the first embodiment. When the processing isstarted, the channel ID is discriminated in step S3901. After that, thesame processing as that in step S1501 and subsequent steps in FIG. 18 isexecuted for the discriminated channel.

FIG. 39B shows the processing procedure started upon write in a DOORBELLregister in the target, and corresponds to FIG. 15 in the firstembodiment. When the processing is started, the channel ID isdiscriminated in step S3911. After that, the same processing as that instep S1601 and subsequent steps in FIG. 15 is executed for thediscriminated channel.

In addition, the processing that starts in response to a data transferrequest (FIG. 14), the processing by the target agent (FIG. 16), and theprocessing upon generation of data to be transferred from the printer tothe host computer (FIG. 17) are the same as those in the firstembodiment. However, before such processing, a channel must be opened.

Also, an ABDICATE RESOURCE request from the target is issued in the samesequence as that of data transfer using DIRECT status from the target.

In this embodiment, data transfer is done by the above-mentionedprocedures. The system of this embodiment is substantially the same asthat in the first embodiment, except that a plurality of logicalchannels can be used.

This system can provide full-duplex communications for each of aplurality of logical channels. For this reason, two-way communicationscan be provided even for equipment having a plurality of devices such asa digital multi-functional machine. Hence, the functions (1) to (6)described in the first embodiment can be provided for a plurality ofchannels.

Other Embodiments

Note that the present invention may be applied to either a systemconstituted by a plurality of equipments (e.g., a host computer,interface device, reader, printer, and the like), or an apparatusconsisting of a single equipment (e.g., a copying machine, facsimileapparatus, or the like).

The objects of the present invention are also achieved by supplying astorage medium, which records a program code (i.e., programs of theprocedures shown in FIGS. 14 to 18 and FIGS. 39A and 39B) of a softwareprogram that can realize the functions of the above-mentionedembodiments to the system or apparatus, and reading out and executingthe program code stored in the storage medium by a computer (or a CPU,MPU, or the like) of the system or apparatus.

In this case, the program code itself read out from the storage mediumrealizes the functions of the above-mentioned embodiments, and thestorage medium which stores the program code constitutes the presentinvention.

As the storage medium for supplying the program code, for example, afloppy disk, hard disk, optical disk, magneto-optical disk, CD-ROM,CD-R, magnetic tape, nonvolatile memory card, ROM, and the like may beused.

The functions of the above-mentioned embodiments may be realized notonly by executing the readout program code by the computer but also bysome or all of actual processing operations executed by an OS (operatingsystem) running on the computer on the basis of an instruction of theprogram code.

Furthermore, the functions of the above-mentioned embodiments may berealized by some or all of actual processing operations executed by aCPU or the like arranged in a function extension board or a functionextension unit, which is inserted in or connected to the computer, afterthe program code read out from the storage medium is written in a memoryof the extension board or unit.

To restate, according to the present invention, full-duplexcommunications that allow asynchronous, two-way communications can berealized by a single login process, and resources such as processes,memories, and the like required for data exchange can be efficientlyused.

Since the initiator and target monitor the empty sizes of each others'queues, an ORB or status block transmitted can be reliably received.

Since the IEEE1394 interface is used, data transfer to the target can bedone when the target reads out data as its resources become available,and the initiator can be prevented from being occupied by data transferon the convenience of the target.

Since SBP-2 is used, an ORB alone is queued in the target, and data tobe transferred itself is stored in the initiator in the processing waittime. For this reason, the memory resources of the target can beminimized.

Using DIRECT status, data of the application layer can be encapsulatedin status of the HPT layer, and can be transmitted from the target tothe initiator. For this reason, the data transfer sequence can beshortened.

Also, multi-channels can be realized.

As many apparently widely different embodiments of the present inventioncan be made without departing from the spirit and scope thereof, it isto be understood that the invention is not limited to the specificembodiments thereof except as defined in the appended claims.

1. A communication control method of exchanging data upon accessing astorage area of an initiator from a target, wherein said initiatortransmits commands corresponding to read and write accesses to saidstorage area to said target so as not to exceed the number of read andwrite commands that can be held by said target, and said target holdsthe received read and write commands in different queues, andindependently processes the held commands. 2-37. (canceled)